home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-thinosi-cookbook-01.txt < prev    next >
Text File  |  1993-10-12  |  65KB  |  1,666 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8. Thinosi Working Group                                        P.R.Furniss
  9. INTERNET DRAFT                                                Consultant
  10.                                                             October 1993
  11.  
  12.  
  13.                   Octet sequences for upper-layer OSI
  14.              to support basic communications applications
  15.  
  16. Status of this Memo
  17.  
  18. This draft document is part of the work of the IETF Thinosi Working
  19. Group. It is intended to submit it to the IAB standards track.
  20. Distribution of this memo is unlimited. Comment on this draft should
  21. be sent to the thinosi mailing list: thinosi@ulcc.ac.uk.  Requests to
  22. join this list should be sent to thinosi-request@ulcc.ac.uk.
  23.  
  24. This document is an Internet-Draft.  Internet-Drafts are working
  25. documents of the Internet Engineering Task Force (IETF), its Areas,
  26. and its Working Groups.  Note that other groups may also distribute
  27. working documents as Internet-Drafts.
  28.  
  29. Internet-Drafts are draft documents valid for a maximum of six months.
  30. Internet-Drafts may be updated, replaced, or obsoleted by other
  31. documents at any time.  It is not appropriate to use Internet-Drafts
  32. as reference material or to cite them other than as a "working draft"
  33. or "work in progress."
  34.  
  35. To learn the current status of any Internet-Draft, please check the
  36. 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  37. Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
  38. munnari.oz.au.
  39.  
  40. The filename of this document in the Internet-Draft directories is
  41. draft-ietf-thinosi-cookbook-01.txt.
  42.  
  43. Abstract
  44.  
  45. This document specifies those elements of the OSI upper-layer
  46. protocols (Session, Presentation and ACSE) needed to support
  47. applications with "basic communications requirements". These include
  48. OSI application protocols such as X.400 P7 and Directory Access
  49. Protocol, and "migrant" protocols, originally defined for use over
  50. other transports.
  51.  
  52. The upper-layer protocol elements are specified in this document as
  53. the particular octet sequences that comprise an "envelope" around the
  54. application protocol's data. It therefore independent, as a document,
  55. from the OSI base standards, although an implementation based on this
  56. document will be able to interwork with an implementation based on the
  57. base standard, when both are being used to support an appropriate
  58. application protocol.
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Expires 17 April 1994                                          [Page 1]
  65.  
  66.  
  67.  
  68. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  69.  
  70.  
  71.  
  72. Table of Contents
  73.  
  74.  1. Introduction .......................................................3
  75.  2. General ............................................................3
  76.    2.1 Subdivisions of "basic communication applications"...............3
  77.    2.2 Conformance and interworking.....................................5
  78.    2.3 Relationship to other documents..................................5
  79.  3. Contexts and titles ................................................6
  80.    3.1 The concepts of abstract and transfer syntax.....................6
  81.    3.2 Use of presentation context by cookbook applications.............7
  82.    3.3. Processing Presentation-context-definition-list.................7
  83.    3.4 Application context..............................................8
  84.    3.5 APtitles and AEqualifiers........................................8
  85.  4. What has to be sent and received ...................................10
  86.    4.1. Sequence of OSI protocol data units used........................10
  87.    4.2. Which OSI fields are used.......................................11
  88.    4.3. Encoding methods and length fields..............................12
  89.    4.3.1 Session items..................................................13
  90.    4.3.2 ASN.1/BER items (Presentation and ACSE)........................13
  91.    4.4. BER Encoding of values for primitive datatypes..................14
  92.    4.5. Unnecessary constructed encodings...............................14
  93.  5. Notation ...........................................................14
  94.  6. Octet sequences ....................................................16
  95.    6.1. Connection request message......................................16
  96.    6.2. Successful reply to connection setup............................18
  97.    6.3. Connection rejection............................................20
  98.    6.4. Data-phase TSDU.................................................20
  99.    6.5. Closedown  - release request....................................21
  100.    6.6. Closedown - release response....................................22
  101.    6.7. Deliberate abort................................................23
  102.    6.8. Provider abort..................................................24
  103.    6.9. Abort accept....................................................24
  104.  7. References .........................................................24
  105.  8. Other notes ........................................................25
  106.  9. Author's Address ...................................................26
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128. Expires 17 April 1994                                          [Page 2]
  129.  
  130.  
  131.  
  132. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  133.  
  134.  
  135.  
  136. 1. Introduction
  137.  
  138. The upper-layer protocols of the OSI model are large and complex,
  139. mostly because the protocols they describe are rich in function and
  140. options. However, for support of most applications, only a limited
  141. portion of the function is needed and the protocol elements needed can
  142. be expressed more simply.
  143.  
  144. This memo describes the protocol elements required by the OSI upper
  145. layers when supporting a connection-oriented application with only
  146. basic communication requirements - that is to create a connection,
  147. optionally negotiate the data representation, send/receive data, close
  148. a connection and abort a connection. Optionally, data may be sent on
  149. the connection establishment, closing and abort messages.
  150.  
  151. The protocol elements for the OSI upper layer protocols (i.e. Session,
  152. Presentation  and Association Control Service Element (ACSE) needed to
  153. support such an application are a subset of the full protocols defined
  154. in the International Standards ([ISO8326, ISO8327, ISO8822, ISO8823,
  155. ISO8649, ISO8650]). Such a protocol subset can be specified in a
  156. profile, which references the base standards and states which parts
  157. are relevant. Such a profile specification cannot be understood
  158. without reference to the base standards.
  159.  
  160. In this memo, the protocol elements needed are specified in terms of
  161. the octet sequences that comprise the 'envelope' around the
  162. application data. This memo can be regarded as an informal re-
  163. specification of the relevant parts of the upper-layer protocols. An
  164. implementation based on this memo will be able to interwork with an
  165. implementation based directly on the full standards when both are
  166. supporting a basic communication application. (The "full"
  167. implementation will exhibit only part of its potential behaviour,
  168. since the application will only invoke part).The envelope and its
  169. enclosing data form a Transport Service Data Unit (TSDU) that can be
  170. passed via the OSI Transport Service [ISO8072] (which in turn may be
  171. supported as specified in [RFC1006] or any class of the OSI Transport
  172. Protocol [ISO8073]).
  173.  
  174.  
  175. 2. General
  176.  
  177. 2.1 Subdivisions of "basic communication applications"
  178.  
  179. Distinctions can be made within the "basic communication
  180. applications", as defined above, based on how much use they make of
  181. the OSI upper-layer services. In particular:
  182.  
  183.       a) whether application data is sent on the connection
  184.       establishment, close and abort, or only during "date phase" on
  185.       an established connection;
  186.  
  187.       b) whether the application data is of only one kind (abstract
  188.       syntax) and one format (transfer syntax) or more than one (i.e.
  189.       how much use is made of the Presentation layer syntax
  190.       negotiation and identification features)
  191.  
  192. Expires 17 April 1994                                          [Page 3]
  193.  
  194.  
  195.  
  196. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  197.  
  198.  
  199.  
  200. These distinctions potentially allow further subsetting, but a large
  201. part of the protocol will be the same. In this memo, four  groups of
  202. supported application are considered, based on these distinctions. All
  203. groups have "basic communications requirements" in requiring only
  204. connection, data transfer and (perhaps) orderly release of
  205. connection.The four groups are:
  206.  
  207.       Group I : applications which send data only on an established
  208.       connection, and use a single abstract and transfer syntax.
  209.  
  210.       Group II : applications which send data on connection
  211.       establishment and release and use a single abstract and transfer
  212.       syntax.
  213.  
  214.       Group III applications that send data of only one kind (one
  215.       abstract syntax) on the connection, but which have more than one
  216.       format (transfer syntax) specified (they use the Presentation
  217.       context negotiation facility)
  218.  
  219.       Group IV applications that will send data of several kinds on
  220.       the connection (and which much therefore distinguish on each
  221.       write which kind is being sent)
  222.  
  223. Group III applications are equivalent to Group I (or possibly Group
  224. II) after the establishment exchange has negotiated the particular
  225. transfer syntax that will be used on the connection.
  226.  
  227. Possible examples of the Groups are:
  228.  
  229.       Group I: Application protocols designed for use over transport-
  230.       level protocols. Typically these are non-OSI protocols
  231.       "migrated" to an OSI environment. X Window System protocol is an
  232.       example.
  233.  
  234.       Group II: OSI-originated protocols with simple requirements,
  235.       including many of the ROSE-based ones, such as Directory Access
  236.       Protocol.
  237.  
  238.       Group III: Protocols that can be treated as Group I, but for
  239.       which more than one encoding of the data is known, such as a
  240.       standardised one and a system-specific one - all implementations
  241.       understand the standard encoding, but Presentation layer
  242.       negotiation allows like-implementations to use their internal
  243.       encoding for transfer, without loss of general interworking. The
  244.       same could apply to OSI protocols.
  245.  
  246.       Group IV: OSI protocols with multiple abstract syntaxes (but
  247.       with each individual message from a single abstract syntax) that
  248.       do not use any of the special Session functional units - X.400
  249.       P7 is an example.
  250.  
  251. Some of the OSI protocols that are not included are those that use
  252. more than one abstract syntax in a single message (such as FTAM or
  253. Transaction Processing) or use Session functional units (RTSE-based
  254. protocols, Virtual Terminal).
  255.  
  256. Expires 17 April 1994                                          [Page 4]
  257.  
  258.  
  259.  
  260. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  261.  
  262.  
  263.  
  264. 2.2 Conformance and interworking
  265.  
  266. The protocol elements specified in this memo correspond to the kernel
  267. functional units of Session, Presentation and ACSE, and the duplex
  268. functional unit of Session.
  269.  
  270. The octet sequences given below are derived from the specifications in
  271. the International Standards for the protocols Session [ISO8327],
  272. Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo
  273. is to summarise those specifications, as applicable to the supported
  274. application groups, so that an implementation could be developed
  275. without direct reference to the original standards, but capable of
  276. interworking with implementations that had made direct reference. The
  277. OSI standards (especially Presentation) allow considerable flexibility
  278. in the encoding of the protocol data units. Accordingly, this memo
  279. defines particular octet sequences to be sent, and describes the
  280. variations that can be expected in data received from an
  281. implementation based directly on the OSI standards, rather than on
  282. this cookbook. It is intended that an implementation that sends these
  283. sequences and that is capable of interpreting the variations described
  284. will be fully able to interwork with an implementation based directly
  285. on the OSI standards. An implementation that is only capable of
  286. interpreting the octet sequences specified in this memo for
  287. transmission may not be able to interwork with standards-based
  288. implementations.
  289.  
  290. The intent is to be able to interwork with conformant implementations
  291. in support of the relevant application (or group of applications).
  292. Some of the OSI standards have conformance requirements that go beyond
  293. that necessary for successful interworking, including detection of
  294. invalid protocol. Tests for conformance sometimes go beyond the strict
  295. conformance requirements of the standard. Consequently an
  296. implementation based on this memo may or may not be able to formally
  297. claim conformance to the International Standard. It may be able to
  298. legitimately claim conformance, but fail a conformance test, if the
  299. test is over-specified. (Efforts are being made to correct this, but
  300. in the meantime, the target is interworking with conformant
  301. implementations.)
  302.  
  303. 2.3 Relationship to other documents
  304.  
  305. The flexibility allowed in the Session, Presentation and ACSE
  306. standards is restricted in the Common Upper-Layer Requirements Part 1
  307. [CULR-1] ). This is a proposed International Standardised Profile
  308. (pdISP 11188-1) that can be assumed to be obeyed by most
  309. implementations. This memo applies the restrictions of CULR-1,
  310. especially where these concern maximum sizes of fields and the
  311. like.Points where advantage is taken of a CULR-1 limitation are noted.
  312.  
  313. Additional parts of CULR are under development. Part 3 [CULR-3] covers
  314. the protocol elements needed for "basic communications applications",
  315. and is being developed in (informal) liaison with this memo. CULR-3 is
  316. presented as a normal profile, largely consisting of prescribed
  317. answers to the questions in the PICS (Protocol Implementation
  318. Conformance Statement) of the three protocols.CULR-3 does not make the
  319.  
  320. Expires 17 April 1994                                          [Page 5]
  321.  
  322.  
  323.  
  324. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  325.  
  326.  
  327.  
  328. distinction between the four Groups.An implementation of this memo (at
  329. least if it supported Group IV) would be able to claim conformance to
  330. CULR-3, with the possible exception of any more-than-interworking
  331. conformance requirements inherited by CULR-3 from the base standards.
  332.  
  333. An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is
  334. shortly to be published as a preliminary specification. This defines
  335. an API to the OSI upper-layers, again as appropriate to a basic
  336. communications application. XTI/mOSI would be usable as an interface
  337. to support applications in groups I, II and III, and possibly group
  338. IV.
  339.  
  340.  
  341. 3. Contexts and titles
  342.  
  343. 3.1 The concepts of abstract and transfer syntax
  344.  
  345. OSI includes the concepts of "abstract syntax" and "transfer syntax".
  346. These are terms for the content (abstract syntax) and format "on-the-
  347. line" (transfer syntax) of the protocol elements. The combination of
  348. an abstract syntax and transfer syntax is called a presentation
  349. context.
  350.  
  351. Application protocols devised explictly under OSI auspices have used
  352. ASN.1 for the definition of the abstract syntax, and nearly all use
  353. the Basic Encoding Rules applied to the ASN.1 to define the transfer
  354. syntax. However, there is no such requirement in OSI in general or in
  355. OSI Presentation, and still less is there any requirement to change
  356. the representation of existing application protocols to ASN.1 (for
  357. their definition) or BER (for their transmission). It is not generally
  358. realised (even in OSI circles) that all communicating applications, in
  359. all environments, are using some form of these, although under
  360. different names and without the explicit identification that the OSI
  361. Presentation provides. OSI separates the identification of the content
  362. and format of the data from the addressing.
  363.  
  364. Formal specifications of non-OSI application protocols (such as
  365. TELNET, FTP, X Windows System) generally do not use ASN.1, but will
  366. invariably be found to define abstract and transfer syntaxes.  For a
  367. less formalised protocol used between similar systems, the abstract
  368. syntax may be defined simply in programming language structures, and
  369. the transfer syntax determined by how some compiler represents this in
  370. memory.
  371.  
  372. The OSI Presentation protocol requires that "names" be assigned to the
  373. abstract and transfer syntaxes of the application data that is
  374. carried. The names are always object identifiers ("oid"): globally
  375. unique names assigned hierarchically. Presentation supports the
  376. negotiation of a transfer syntax for a particular abstract syntax -
  377. several can be offered and one selected.
  378.  
  379. This transfer syntax negotiation facility may be especially useful for
  380. non-ASN.1 syntaxes where there is more than one representation
  381. available (perhaps differing in byte-ordering or character code). In
  382. such a case, on the connection establishment, all of the transfer
  383.  
  384. Expires 17 April 1994                                          [Page 6]
  385.  
  386.  
  387.  
  388. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  389.  
  390.  
  391.  
  392. syntaxes supported by the initiatior are offered, and any one of these
  393. accepted by the responder, at its own choice. If the two systems share
  394. some "native" format they can negotiate that, avoiding transformation
  395. into and out of a more general format that is used for interworking
  396. with unlike systems. The same applies to an ASN.1-defined abstract
  397. syntax, but in practice non-BER encodings of ASN.1 are rare.
  398.  
  399. 3.2 Use of presentation context by cookbook applications
  400.  
  401. An application protocol not originally specified with OSI Presentation
  402. in mind (a "migrant" protocol) will not normally need  to identify the
  403. abstract and transfer syntaxes being used - they are known by some
  404. other means (effectively inferred from the addressing).  A generic
  405. (anonymous, if you like) name for both syntaxes can be used and [CULR-
  406. 3] defines object identifiers for "anonymous"  abstract and transfer
  407. syntax names (currently called "default", but this is expected to
  408. change).
  409.  
  410. In some cases object identifier names will be assigned for the
  411. syntaxes of a migrant application protocol. If these exist, they
  412. should be used. However, since the processing required will be the
  413. same, it will be legitimate to offer both the generic and specific
  414. names, with the responder accepting the specific (if it knew it) and
  415. the generic if the specific were not known - this will provide a
  416. migration option if names are assigned to the syntaxes after
  417. implementations are deployed using the generic names.
  418.  
  419. For abstract syntaxes defined in ASN.1 object identifier names will
  420. have been assigned to the abstract syntax with the specification. This
  421. name MUST be used to identify the abstract syntax. The transfer syntax
  422. will most often be the Basic Encoding Rules (BER) object id, but
  423. alternatives (e.g. Packed Encoding Rules) are possible.
  424.  
  425. For group III and group IV applications, specific object identifier
  426. names must be used for all the abstract and transfer syntaxes. If
  427. these names are not assigned with the specification (e.g. if the
  428. specification not in ASN.1) they can be assigned by whoever needs them
  429. - ideally the "owner" of the syntax specification.
  430.  
  431. 3.3. Processing Presentation-context-definition-list
  432.  
  433. In Presentation context negotiation on connection establishment the
  434. initiator sends a list (the presentation context definition list) of
  435. the abstract syntaxes it intends to use, each with a list of transfer
  436. syntaxes. Each presentation context also has an integer identifier. To
  437. build the reply, a responder has to examine this list and work out
  438. which of the offered presentation contexts will be accepted and which
  439. (single) transfer syntax for each. The responder sends back the reply
  440. field, the Presentation-context-definition-result-list, in the accept
  441. message. The result list contains the same number of result items as
  442. the definition-list proposed presentation-contexts. They are matched
  443. by position, not by the identifiers (which are not present in the
  444. result-list). An acceptance also includes the transfer syntax accepted
  445. (as there can be several offered). This can be copied from the
  446. definition list.
  447.  
  448. Expires 17 April 1994                                          [Page 7]
  449.  
  450.  
  451.  
  452. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  453.  
  454.  
  455.  
  456. For the group I, group II and group III cases,  only the ACSE and one
  457. application-data P-context will be used and all other contexts
  458. rejected. For the group IV case, several presentation contexts will be
  459. accepted.
  460.  
  461. However, even for group I applications there may be synonyms for an
  462. application-data Presentation-context. Unknown synonyms are rejected.
  463. The reply shown in 6.2 includes a rejection (It can therefore not be
  464. the reply to the connection request shown in 6.1, since that has only
  465. two items in the definition list.)
  466.  
  467. In all cases, the connection responder must identify and keep the
  468. presentation context identifiiers (called pcid's here) for all the
  469. accepted presentation contexts. These are integers (odd integers, in
  470. this case). CULR-1 limits them to no greater than 32767, but they will
  471. usually be <= 255 (so taking up one octet).
  472.  
  473. A presentation context is sometimes used (i.e. data is sent using it)
  474. before the negotiation is complete. As will be seen in section 6, in
  475. these cases, the transfer syntax name sometimes appears with the
  476. integer identifier.
  477.  
  478. 3.4 Application context
  479.  
  480. The Association Control Service Element also exchanges the name
  481. (another Object Identifier) of the application context, which
  482. identifies what the communication is all about, again independently of
  483. the naming and addressing.  As for the syntaxes, although some name
  484. must be present in the protocol, a generic name can be used for
  485. applications that do not have a specific name assigned. (This will
  486. almost certainly be a group I application - if a specific name is
  487. assigned, it MUST be used.) The only negotiation allowed is that the
  488. reply may be different from that sent by the initiator. CULR-3
  489. provides a generic application context name (i.e. assigns an object
  490. identifier).
  491.  
  492. 3.5 APtitles and AEqualifiers
  493.  
  494. In addition to the addressing constructs (transport address and
  495. possibly session and presentation selectors), the communicating
  496. application entities have names - Application-Entity titles (AEtitle).
  497. These are carried by ACSE as two fields -the Application-process
  498. titles (APtitle) and the Application-entity qualifier (AEqualifier).
  499. The AEtitle is compound, and the APtitle consists of all but the last
  500. element, which is the AEqualifier. (This explanation can be run
  501. backwards). There are two non-equivalent forms. AP-titles and AE-
  502. titles can be Directory Name or an Object Identifier. AE-qualifiers
  503. can be Relative Distinguished Name (RDN) or an integer - the forms
  504. must match, since the AE-qualifier is the last component of the AP-
  505. title. In practice, the Directory form is likely to be the only one
  506. seen for a while.
  507.  
  508. Use of the these names is rather variable. This cookbook proposes that
  509. implementations should be able to handle any value for the partner's
  510. names, and set (as initiator) its own names. This is primarily to
  511.  
  512. Expires 17 April 1994                                          [Page 8]
  513.  
  514.  
  515.  
  516. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  517.  
  518.  
  519.  
  520. facilitate OSI:non-OSI relaying (e.g. X/osi:X/tcp), allowing the names
  521. of the end-system to be carried to the relay, where they can be
  522. converted into hostnames, and the lower-layer address determined. OSI
  523. assumes that name-to-address lookup is possible (via the Directory or
  524. other means), but does not assume address-to-name will work. Thus the
  525. calling AE-title is needed if the responder is to know who the
  526. initiator is. However, most protocols work perfectly well without
  527. these names being included.
  528.  
  529. As for their encoding, a RDN will almost always be a single attribute
  530. value assertion, with the attribute defined either by the Directory
  531. standard [ISO9594 = X.500], or in [Internet/Cosine Schema][RFC1274].
  532. Using the notation defined below, the encoding of an RDN using a
  533. Directory-defined standard attribute is:
  534.  
  535. 31  80  {1         - RDN, [SET OF]
  536. 30  80  {2         - AttributeValueAssertion, [SEQUENCE]
  537. 06  03  5504yy     -- OID identifying an attribute named in
  538.                    -- the Directory standard
  539.                    -- which one is determined by yy
  540. 13  La  xxxxxx     -- [Printable string]
  541.                    -- could be T61 string, with tag 14
  542. 00  00  }2         - end of AVA
  543. 00  00  }1         - end of RDN
  544.  
  545. The most likely attributes for an RDN have the following hex values
  546. for yy
  547.  
  548.      CommonName               03
  549.      Country                  06
  550.      Locality                 07
  551.      State/Province           08
  552.      Organisation             0A
  553.      OrganisationUnit         0B
  554.  
  555. For non-Directory attributes, the object id name must be substituted
  556. (thus changing the immediately preceeding length)
  557.  
  558. If there are multiple attribute value assertions in the RDN, the group
  559. between {2 and 2} is repeated (with different attributes). Order is
  560. not significant.
  561.  
  562. The encoding of a [Directory] Name for the AP-titles is the RDNs
  563. (high-order first) within
  564.  
  565. 30  80  {1        - [SEQUENCE] Name
  566.  -- put the RDN encodings here
  567. 00  00  }1
  568.  
  569. An Object Identifier AP-title is encoded as a primitive (see below),
  570. with the "universal" tag for an object identifier, which is 6. The
  571. integer AE-qualifer uses the universal tag for an integer, which is 2.
  572.  
  573.  
  574.  
  575.  
  576. Expires 17 April 1994                                          [Page 9]
  577.  
  578.  
  579.  
  580. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  581.  
  582.  
  583.  
  584. 4. What has to be sent and received
  585.  
  586. 4.1. Sequence of OSI protocol data units used
  587.  
  588. OSI defines its facilities in terms of services but these are abstract
  589. constructs (they do not have to correspond to procedure calls) - the
  590. significant thing is the transmission of the resulting  protocol data
  591. unit (PDU). The PDU at each layer carries (as user data) the PDU of
  592. the layer above. The different layers follow different conventions for
  593. naming the pdus. This section gives an overview of the sequence of
  594. PDUs exchanged - the details of these are given in section 6.
  595.  
  596. The requirements of the application are to create a
  597. connection(strictly an association for the application-layer in OSI,
  598. but called a connection here), to send and receive data and to close
  599. the connection.  The PDUs used are thus:
  600.  
  601. To create connection :
  602.  
  603.         First create transport-level connection
  604.  
  605.         Initiator sends the message defined in 6.1, which is Session
  606.         CONNECT carrying Presentation CONNECT request [CP] carrying
  607.         ACSE A-ASSOCIATE request [AARQ] optionally carrying
  608.         application data.
  609.  
  610.         Responder replies with the message defined in 6.2, which is
  611.         Session ACCEPT carrying Presentation CONNECT response [CPA]
  612.         carrying ACSE response [AARE] optionally carrying application
  613.         data.
  614.  
  615.      -  If the responder rejects the attempt, the reply will be
  616.         Session REJECT. This is defined in 6.3, where the REJECT
  617.         carries no user data. A received REJECT may carry
  618.         Presentation, ACSE and application data, although 6.3 shows
  619.         only how to reject at Session level..
  620.  
  621. To send/receive data on an connection
  622.  
  623.         send the message defined in 6.4, which is an empty Session
  624.         GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
  625.         DATA [TD] containing the application data (The GIVE-TOKEN is
  626.         just two octets required by Session for some backwards
  627.         compatibility)
  628.  
  629. To close connection gracefully
  630.  
  631.         One side sends the message defined in 6.5, which is Session
  632.         FINISH carrying P-RELEASE request carrying A-RELEASE request
  633.         [RLRQ] optionally carrying application data (This side may now
  634.         receive, but not send data)
  635.  
  636.         The other side replies with the message defined in 6.6, which
  637.         is Session DISCONNECT carrying P-RELEASE response carrying A-
  638.         RELEASE response [RLRE] optionally carrying application data
  639.  
  640. Expires 17 April 1994                                         [Page 10]
  641.  
  642.  
  643.  
  644. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  645.  
  646.  
  647.  
  648.         First side disconnects transport connection on receiving the
  649.         reply
  650.  
  651. To close connection abruptly but also send application data
  652.  
  653.         Send the message defined in 6.7, which is Session ABORT
  654.         carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
  655.         carrying application data (delivery not guaranteed)
  656.  
  657.         On receiving Session ABORT, disconnect transport
  658.  
  659. To close connection abruptly
  660.  
  661.      -  Either send the message defined in 6.8, which is Session ABORT
  662.         carrying nothing;
  663.  
  664.         Or, just disconnect at transport level
  665.  
  666. A group I application is assumed (by definition) not to send data on
  667. the establishment and release exchanges, a group II application will.
  668.  
  669. It would be possible to use the abort-with-data facility with a group
  670. I to send a (possibly non-standardised) error message for diagnostic
  671. purposes.
  672.  
  673. A special rule is used if a release collision occurs (i.e. FINISH+P-
  674. RELEASE+RLRQ received after sending the same): the side that initiated
  675. the original upper-layer connection waits and the other side replies
  676. with the DISCONNECT etc.
  677.  
  678.  
  679.  
  680. 4.2. Which OSI fields are used
  681.  
  682. There are a number of fields (parameters) in the pdus involved. These
  683. can be categorised by what is needed to support applications (of a
  684. particular Group) in general - a field may  be "useful", "send-only",
  685. "fixed", "fixed with default", "internal" or "not important". Even
  686. those that are not important may be received from another
  687. implementation, but since the application has no use for them, they
  688. can be ignored. If an implementation is intended to support only a
  689. particular application, it may be able to downgrade the "useful" to
  690. "not important"
  691.  
  692. The text below describes the processing that is required for each
  693. category and which fields are in each category.
  694.  
  695. "Useful" - when sending, the implementation SHOULD be able to set any
  696. (legal) value of these fields (via the upper interface from the
  697. application or via some configuration or lookup mechanism) and SHOULD
  698. pass received values for the Calling values to the application (for
  699. specific applications, these fields may be either required or
  700. unnecessary.)
  701.  
  702.     AARQ:
  703.  
  704. Expires 17 April 1994                                         [Page 11]
  705.  
  706.  
  707.  
  708. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  709.  
  710.  
  711.  
  712.       Called application-process title
  713.       Called application-entity qualifier
  714.       Calling application-process title
  715.       Calling application-entity qualifier
  716.  
  717. "Send-only" - the implementation MUST be able to set any value of
  718. these, but can ignore any received value. Both are octet strings.
  719.  
  720.       Presentation selector (up to 4 octets, limited by CULR-1)
  721.       Session selector (up to 16 octets, limited by base standard)
  722.  
  723.  
  724. "Fixed" (constant for all applications)
  725.  
  726.       abstract and transfer syntax identifiers for presentation
  727.       context for ACSE
  728.       Version numbers - 2 for session, 1 for Presentation and ACSE
  729.  
  730.  
  731. "Fixed with default" - the value is specific to the application. For
  732. non-ASN.1 abstract syntaxes (group I or group II only) applications,
  733. the anonymous values assigned by the OIW minimal OSI profile [CULR-3]
  734. can be used. The CULR-3 default application context can be used where
  735. a proper context name is neither available nor needed.
  736.  
  737.       Application context
  738.                        CULR-3  default is {1 0 11188 3 3}
  739.       Abstract syntax identifier for application data
  740.                        CULR-3 anonymous name is {1 0 11188 3 1 1}
  741.       Transfer syntax identifier for application data
  742.                        CULR-3 anonymous name is {1 0 11188 3 2 1}
  743.  
  744.  
  745. "Internal" - an arbitrary value can be sent; a received value must be
  746. stored for use in sending.
  747.  
  748.       Presentation context identifiers for ACSE and the application
  749.       data (always odd integers)
  750.  
  751. "Not important" - any legal received value for the other fields MUST
  752. be received (i.e. the pdu is parsed successfully), but can then be
  753. ignored. There is no requirement (in this cookbook) to check the
  754. existence, value or internal format of these fields.
  755.  
  756.       All other fields (which includes a large number of session
  757.       fields)
  758.  
  759. 4.3. Encoding methods and length fields
  760.  
  761. Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value
  762. structure for their encodings, but different ones. Presentation
  763. protocol and ACSE protocol use the ASN.1/BER encoding and consequently
  764. a Presentation PDU containing an ACSE PDU can be constructed or parsed
  765. as if it were a single structure.
  766.  
  767.  
  768. Expires 17 April 1994                                         [Page 12]
  769.  
  770.  
  771.  
  772. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  773.  
  774.  
  775.  
  776. All the protocols contain pdu fields with a compound structure. If one
  777. of these is being ignored it may be necessary (for BER, not session)
  778. to determine the lengths of its components to find the length of the
  779. ignored field.
  780.  
  781. Many of the lengths in the specification below will vary, dependent on
  782. the values of the fields.
  783.  
  784. 4.3.1 Session items
  785.  
  786. The type field of a session item is always a single octet.
  787.  
  788. For session items, given a particular length, there is no flexibility:
  789.  
  790.       If the length is less than 255, represent as one octet
  791.  
  792.       If the length is greater, represent as three octets, first is
  793.       0xFF, next two are the length, high-order octet first.
  794.  
  795. (Some "real" implementations are known to use the second encoding in
  796. all cases. This is wrong, but should only concern conformance
  797. testers.)
  798.  
  799. 4.3.2 ASN.1/BER items (Presentation and ACSE)
  800.  
  801. The type field for ASN.1-BER is the tag. Although it is possible for
  802. large tags (>30) to be multi-octet, there are no large tags in the
  803. protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1 if
  804. the item is constructed (i.e. the value is itself one or more ASN.1
  805. BER items) or 0 if it is primitive.
  806.  
  807. There is considerable flexibility, at senders option, in how lengths
  808. are represented in BER. There are three forms: short, long and
  809. indefinite.
  810.  
  811.       Short (usable only if the length is less than 127) : one octet
  812.  
  813.       Long (usable for *any* length) : first octet has the top bit
  814.       set, the rest is a count of how many octets are holding the
  815.       length value; that many subsequent octets hold the length. A
  816.       long length may use more than the minimum number of octets (so
  817.       0x8400000001 is a valid representation of length 1)
  818.  
  819.       Indefinite (usable only for the length of a compound field) :
  820.       the single octet is 0x80, then one or more items (their tag-
  821.       length-values) and finally two octets of 0x00 (equivalent to tag
  822.       and length of zero).
  823.  
  824. To be able to interwork generally, an implementation must be able to
  825. handle any of these forms when receiving.
  826.  
  827. The encodings specified in the octet sequences below use indefinite
  828. length for all constructed items with a few exceptions. This slightly
  829. increases the number of octets sent, but means that the length of a
  830. varying field (e.g. user data, or a varying object identifier) affects
  831.  
  832. Expires 17 April 1994                                         [Page 13]
  833.  
  834.  
  835.  
  836. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  837.  
  838.  
  839.  
  840. only the length of the item itself, and not the enclosing lengths. It
  841. is thus possible to use the octet sequences as templates interspersed
  842. by the varying fields.
  843.  
  844. It is important to note that this choice of indefinite (which is
  845. equivalent to the "Canonical Encoding Rules" variant of BER) applies
  846. only to the Presentation and ACSE protocols themselves. It does not
  847. apply to ASN.1/BER encoded application data. The processing required
  848. of application data may suggest alternative "best" options.
  849.  
  850. 4.4. BER Encoding of values for primitive datatypes
  851.  
  852. The following ASN.1 primitive datatypes are used in the thinosi
  853. stack..
  854.  
  855. Integers are encoded in twos-complement, high-order first. Unlike
  856. lengths, they must be encoded in the minimum number of octets (no
  857. leading 00 padding).
  858.  
  859. Object Identifiers have a rather peculiar, but compressed encoding:
  860.  
  861.       Combine the first two integers of the OID into one element by
  862.       multiplying the first (always 0, 1 or 2) by 40, and add the
  863.       second.
  864.  
  865.       Each element (that one, and each subsequent integer in the OID
  866.       taken on its own), is a taken as a binary number and divided
  867.       into 7-bit "bytes". This is apportioned into bits 1-7 of the
  868.       minimum number of octets. Bit 8 is one for all octets of the
  869.       sequence except the last. (This means that elements of less than
  870.       127 are single octet integers.)
  871.  
  872. Printable Strings - as if in ISO 646 (ASCII)
  873.  
  874. OCTET STRING - just put the octets there
  875.  
  876. 4.5. Unnecessary constructed encodings
  877.  
  878. BER allows the sender to break some items (such as OCTET STRINGS,
  879. character strings) into several pieces (i.e. as constructed encoding)
  880. or send them as primitive. CULR-1 requires that this is only done to
  881. one level. The pieces of both OCTET STRING and character string are
  882. tagged as if they were OCTET STRING - they have the tag 04. This memo
  883. does not include any of these optional constructions, but they may be
  884. received in interworking.
  885.  
  886.  
  887. 5. Notation
  888.  
  889. The constructs are shown in their tag - length - value form. All
  890. numbers are in hexadecimal. Comments are preceded by a '-' character.
  891. Multiple '-' mean the comment is more than just information.
  892.  
  893. The tag column contains one of:
  894.  
  895.  
  896. Expires 17 April 1994                                         [Page 14]
  897.  
  898.  
  899.  
  900. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  901.  
  902.  
  903.  
  904.       single fixed octets.
  905.  
  906.       * in the tag field indicates one or more pdu fields (possibly
  907.       constructed) that may be received but are not sent. If received
  908.       they can be ignored.
  909.  
  910.       ! indicates the tag is defined elsewhere.
  911.  
  912.       .  is a place holder for the column.
  913.  
  914.       ? preceding the tag value indicates that the field is not always
  915.       present - the comment will explain.
  916.  
  917. The length column contains one of
  918.  
  919.       explicit value
  920.  
  921.       Ls - a length according to session rules which depends on the
  922.       total size of the value (usually constructed)
  923.  
  924.       La - a length according to BER rules
  925.  
  926.       . is a placeholder
  927.  
  928.       yy is exactly one octet (i.e. one hex digit per y) holding part
  929.       of the length
  930.  
  931. The value column contains one of
  932.  
  933.       the hex value
  934.  
  935.       xxxxxx - value of varying length (sometimes constructed)
  936.  
  937.       {n - (n = number) the start of a constructed value
  938.  
  939.       n - (n=number) the end of the constructed value with the
  940.       corresponding number. (The number is sometimes omitted on the
  941.       innermost nest of construction)
  942.  
  943.       yy - as part of a value - a variable value, each y represents
  944.       one hex digit
  945.  
  946.       ? a value, possibly constructed that may be received but is not
  947.       sent. It may be ignored if received
  948.  
  949. Note that all presentation lengths may be received in one of the
  950. alternative forms. All constructed lengths are shown in indefinite
  951. form. If a received length is definite, the corresponding end item
  952. (which will be shown here as 00 00 }n)  will become  . . }n.
  953.  
  954. In the comments, the notation {n} refers to the constructed item
  955. bracketed by the {n, }n fields.
  956.  
  957.  
  958.  
  959.  
  960. Expires 17 April 1994                                         [Page 15]
  961.  
  962.  
  963.  
  964. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  965.  
  966.  
  967.  
  968. 6. Octet sequences
  969.  
  970. 6.1. Connection request message
  971.  
  972.      - CONNECT SPDU
  973. 0D  Ls  {1       - "SI" value for CONNECT = 13
  974. *   Ls  ?        - Connection Identifier
  975. 05  06  {2       - Connect/Accept Item
  976. 13  01  00       - protocol options (probably mandatory)
  977. *   Ls  ?
  978. 16  01  02       -- version number (bottom bit = v1, next bit =v2.
  979.                  --     may get offers of either or both
  980. *   Ls  ?
  981. .   .   }2       - End Connect/Accept Item
  982. 14  02  0002     - Session User Requirements (functional units)
  983.                  - Id (20), length (always 2), duplex fu only.
  984.                  -- On receipt, other bits may be set
  985.                  -- check that the 2 bit is set
  986. *   Ls  ?        - we do not send any Calling Session Selector
  987. ?34 Ls  xxxx     -- Called Session Selector (i.e. the other end's)
  988.                  -- up to 16 octets - you must set what the other side
  989.                  -- demands.  - May be anything characters, binary etc.
  990.                  -  {3} disappeared in editing
  991. C1  Ls  {4       -- User Data, Identifier=193. if length is > 512,
  992.                  -- then identifier is 194 (hex C2) instead
  993. - CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
  994. 31  80  {5       - [SET]
  995.            --- Mode-selector (the {6} group) could possibly
  996.            --- come after everything else {7}
  997.            --- This will probably only be done by
  998.            --- evil-minded conformance testers
  999. A0  80  {6       - Mode-selector [0] IMPLICIT SET
  1000. 80  01  01       - [0] IMPLICIT INTEGER {normalmode(1)}
  1001. 00  00  }6
  1002. A2  La  {7       - [2] unnamed IMPLICIT SEQUENCE
  1003. *   La  ?
  1004. ?82 La  xxxx     - [2] Called-presentation-selector
  1005.                  - CULR says maximum length is 4
  1006.                  -- must be what the other side wants
  1007. A4  80  {8       - [4] Presentation-context-definition-list
  1008.              ---  items (the outer SEQUENCEs) within the {8} list may
  1009.              ---  be in any order.
  1010. 30  80  {9       - [SEQUENCE]
  1011. 02  01  01       -- Defines pcid for ACSE; received value will be
  1012.                  -- a one or two octet odd integer
  1013. 06  04  52010001 - [OID] for ACSE abstract syntax
  1014. 30  80  {        - [SEQUENCE]
  1015. 06  02  5101     - [OID] Transfer syntax name is BER
  1016. 00  00  }        - end t-s list
  1017. 00  00  }9       - end acse pctx defn
  1018. 30  80  {10      - [SEQUENCE]
  1019. 02  01  03       -- [INTEGER] Defines pcid for application data;
  1020.                  -- received value will be a one or two octet odd
  1021.                  -- integer
  1022. 06  La  xxxxxx   - [OID] object identifier name of application abstract
  1023.  
  1024. Expires 17 April 1994                                         [Page 16]
  1025.  
  1026.  
  1027.  
  1028. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1029.  
  1030.  
  1031.  
  1032.                  -  syntax (if CULR-3 default is used, this line is
  1033.                  -  06  06  28CC64030101)
  1034. 30  80  {11
  1035. 06  La  xxxxxx   - [OID] t-s name for application data
  1036.                  - (if CULR-3 default is used, this line is
  1037.                  -  06  06  28CC64030201)
  1038.              -- will be several of these if multiple t-s offered
  1039.              -- (application is Group III)
  1040.              -- all will have the same tag 06
  1041. 00  00  }11      - end transfer syntax list for application p-ctx
  1042. 00  00  }10       - end application pctx definition
  1043.              -- if multiple presentation contexts are offered, (Group
  1044.              -- IV), the {10} SEQUENCE will repeat appropriately
  1045.              -- if multiple contexts are to be accepted, all the pcid's
  1046.              -- must be remembered
  1047. 00  00  }8       - end of p-ctx-def-list
  1048. *   La  ?
  1049. 61  80  {12      - [APPLICATION 1] User-data - Fully-encoded
  1050. 30  80  {13      - [SEQUENCE] PDV-list
  1051. 02  01  01      -- [INTEGER], value is acse pcid
  1052. A0  80  {14      - [0] Single-ASN1
  1053. - ACSE A-ASSOCIATE request APDU - AARQ
  1054. 60  80  {15      - [APPLICATION 0] - AARQ
  1055. *   La  ?        -  protocol version defaults to 1 (only one defined)
  1056. A1  80  {        - [1] Application-context
  1057. 06  La  xxxxxx   -- object identifier name of application context
  1058.                  - (if CULR-3 default is used, this line is
  1059.                  -  06  05  28CC640303)
  1060. 00  00  }
  1061.           -- Called application process title {16} and application
  1062.           -- entity qualifier may or may not be needed (see 3.4)
  1063. ?A2 80  {16      - [2] Called Application-Process title
  1064. ?!  La  xxxxxx   -- see 3.5 - either a Directory Name or an oid
  1065. ?00 00  }16      - end Called APtitle
  1066. ?A3 80  {17      - [3] Called Application-Entity Qualifier
  1067. ?!  La  xxxxxx   -- see 3.5
  1068. ?00 00  }17
  1069. *   La  ?
  1070.           Calling AP-title and AE-qualifier may or may not be needed.
  1071. ?A6 80  {18      - [6] Calling Application-Process title
  1072. ?!  La  xxxxxx   -- see 3.5
  1073. ?00 00  }18
  1074. ?A7 80  {19      - [7] Calling Application-Entity Qualifier
  1075. ?!  La  xxxxxx   -- see 3.5
  1076. ?00 00  }19
  1077. *   La  ?
  1078.          -- the user information field may or may not be required
  1079.          -- (not required for Group I)
  1080. ?BE 80  {20      - [30] IMPLICIT SEQUENCE
  1081. ?08 80  {21      - [EXTERNAL]
  1082. ??06 La xxxxxx   -- [OID] This is the oid identifying the transfer
  1083.                  -- syntax used for the user data.
  1084.                  -- It is (almost certainly) required even if only
  1085.                  -- one transfer syntax was proposed.
  1086. ?02 01  03       -  [INTEGER] this is the pcid for the application data
  1087.  
  1088. Expires 17 April 1994                                         [Page 17]
  1089.  
  1090.  
  1091.  
  1092. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1093.  
  1094.  
  1095.  
  1096. ?A0 La  xxxxxx   -- [0] single-ASN.1-type - the application data
  1097.                  --      (see paragraph at end of this section below}
  1098. ?00 00  }21      - end of EXTERNAL
  1099.          -- conceivably there may be several EXTERNALS, probably in
  1100.          -- different presentation contexts (different pcids)
  1101. ?00 00  }20      - end of user information field
  1102. 00  00  }15      - end of AARQ
  1103. 00  00  }14      - end of single-ASN-type
  1104. 00  00  }13      - end of PDV-list
  1105. 00  00  }12      - end of Presentation User-data
  1106. 00  00  }7       - end of third element of CP-type SET
  1107. 00  00  }5       - end of CP-type
  1108. .   .   }4       - end of session user data
  1109. .   .   }1       - end of CONNECT SPDU
  1110.  
  1111. The application data carried in the EXTERNAL is shown (as A0 La xxxx)
  1112. assuming it is a single-ASN.1 type, which it often will be for group
  1113. II (since these tend to be OSI applications). The xxxx will be the BER
  1114. encoding of the application pdu (probably something like Z-BIND or Y-
  1115. INITIALIZE). The length may be indefinite.
  1116.  
  1117. If the application data is not a single ASN.1 type, but is an octet-
  1118. aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx is
  1119. the value. In this case the length must be definite (unless an
  1120. "unecessary" constructed encoding is used.)
  1121.  
  1122. Identical considerations apply to the other EXTERNALs carried in the
  1123. ACSE pdus.
  1124.  
  1125. 6.2. Successful reply to connection setup
  1126.  
  1127. If the connection attempt is succesful, the following is sent to the
  1128. initiator on a T-DATA.
  1129.  
  1130. This accept contains an item {9} in the presentation-context-result-
  1131. list which is the rejection of some presentation context that was
  1132. offered. This is included to show such a rejection. It is NOT included
  1133. if this is the reply to the connect in 6.1.
  1134.  
  1135.  
  1136. 0E  Ls  {1         - ACCEPT SPDU
  1137. *   Ls  ?
  1138. 05  06  {2         - Connect/Accept Item
  1139. 13  01  01         - Protocol Options
  1140. *   Ls  ?
  1141. 16  01  02         - version number (this shows version 2 only)
  1142.                -- if version 2 was not offered, omit all of {2}
  1143. *   Ls  ?
  1144. .   .   }2         - End Connect/Accept Item
  1145. 14  02  0002       - Session User Requirements (functional units)
  1146.                    - duplex fu only (kernel is automatic)
  1147. *   Ls  ?
  1148. C1  Ls  {3         -- User Data.( tag is C2 if length > 512 )
  1149.   - CPA - P-CONNECT response
  1150. 31  80  {4         - [SET]
  1151.  
  1152. Expires 17 April 1994                                         [Page 18]
  1153.  
  1154.  
  1155.  
  1156. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1157.  
  1158.  
  1159.  
  1160.                    -- again, Mode-selector could come at the end
  1161. A0  80  {          -  Mode-selector [0], length=3
  1162. 80  01  01         - normal mode - [0], length=1, value=1
  1163. A2  80  {5         - [2] SEQUENCE (unnamed)
  1164. *   La  ?
  1165. A5  80  {6         - [5] P-context-definition-result-list
  1166.                 -- following result items are in the order corresponding
  1167.                 -- to the pctx-definition-list in the connect
  1168.                 -- this example assumes that was ACSE, user, rubbish
  1169.                 -- with rubbish rejected
  1170. 30  80  {7         - [SEQUENCE] result item for acse
  1171. 80  01  00         -- [0] result, value 0 is acceptance
  1172. 81  02  5101       -  [1] accepted transfer syntax name = BER
  1173.                    - note that this has an implicit tag, not 06
  1174. 00  00  }7         - end result item for acse p-ctx
  1175.  
  1176. 30  80  {8         - [SEQUENCE] result item for application-data pctx
  1177. 80  01  00         - [0] value 0 is acceptance
  1178. 81  La  xxxxxx     - [1] oid for transfer syntax, as on defintion list
  1179.                    -- if there were several (groupIII) , the one you
  1180.                    -- liked most
  1181. 00  00  }8         - end result item for app-data p-ctx
  1182.                    -- next SEQUENCE is a rejection of a third pctx
  1183. 30  80  {9         - [SEQUENCE] result item for a rejected pctx
  1184. 80  01  02         -- [0] result, value 2 is provider rejection
  1185. 82  01  00         - [2] reason, value 0 is reason-not-specified
  1186.                    -- there are other reasons, but let's keep it simple
  1187. 00  00  }9         - end result item for rejected pctx
  1188. 00  00  }6         - end p-ctx-def-result-list
  1189. *   La  ?
  1190. 61  80  {10        - [APPLICATION 1] User-data, Fully-encoded
  1191.  
  1192. 30  80  {11        - [SEQUENCE] PDV-list
  1193. 02  01  01         -- [INTEGER] value is pcid for ACSE, as stored from
  1194.                    -- the pctx-definition-list on the P-CONNECT request
  1195. A0  80  {12        - [0] single-ASN1-type
  1196.      - A-ASSOCIATE response APDU - AARE
  1197. 61  80  {13        - [APPLICATION 1] identifies AARE
  1198. *   La  ?
  1199. A1  80  {14        - [1] Application-context
  1200. 06  La  xxxxxx     - [OID] name of application context
  1201.                    - usually the same as on AARQ, can differ
  1202. 00  00  }14
  1203. A2  03  {15        - [2] result
  1204. 02  01  00         - [INTEGER] value 0 means accepted
  1205. 00  00  }15
  1206. A3  80  {16        - [3] result-source-diagnostic
  1207.                    - (curiously, a non-optional field)
  1208. A1  80  {17        - [1] acse-service-user
  1209. 02  01  00         - [INTEGER] value 0 = null ! (why no implicit tag)
  1210. 00  00  }17        - end acse-service-user
  1211. 00  00  }16        - end result source diagnostic
  1212. *   La  ?
  1213.          -- the user information field may or may not be required
  1214.          -    (not used for Group I)
  1215.  
  1216. Expires 17 April 1994                                         [Page 19]
  1217.  
  1218.  
  1219.  
  1220. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1221.  
  1222.  
  1223.  
  1224. ?BE 80  {20      - [30] IMPLICIT SEQUENCE
  1225. ?08 80  {21      - [EXTERNAL]
  1226.                 -- the transfer-syntax oid is not present this time
  1227. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1228. ?A0 La  xxxx     -- [0] single-ASN1-type (see note at end of 6.1)
  1229. ?00 00  }21      - end of EXTERNAL
  1230.          -- conceivably there may be several EXTERNALS, probably in
  1231.          -- different presentation contexts (different pcids)
  1232. ?00 00  }20      - end of user information field
  1233. 00  00  }13        - end AARE
  1234. 00  00  }12        - end single-asn1-type
  1235. 00  00  }11        - end PDV-list
  1236. 00  00  }10        - end Presn user-data
  1237. 00  00  }5         - end [2] implicit sequence in cpa
  1238. 00  00  }4         - end CPA-type set
  1239. .   .   }3         - end session userdata
  1240. .   .   }1         - end ACCEPT SPDU
  1241.  
  1242.  
  1243. 6.3. Connection rejection
  1244.  
  1245. Refusal is at session-level, but by session user, with no reason
  1246. given. This is a compromise avoiding making unfounded accusations of
  1247. (session) protocol misbehaviour. If the implementation finds it does
  1248. not like the received message, it is not essential to attempt to
  1249. communicate with the partner why, though this may be helpful if the
  1250. reason is correctly identified. (In most cases, a wise implementor
  1251. will make sure an error message goes somewhere or other).
  1252.  
  1253.  
  1254. 0C  03  {1          - REFUSE SPDU
  1255. *   Ls  ?
  1256. 32  01  00          - rejected by SS-user, no reason
  1257. .   .   }1
  1258.  
  1259.  
  1260. The far-end may send interesting things explaining why you are not
  1261. getting interworking. If this is a session reason, the reason code
  1262. will one octet between 81 and 86. If the rejection is higher than
  1263. session, this will be carried on S-REFUSE (so first octet is still 0C)
  1264. and the higher pdu will appear as part of the reason code, which will
  1265. start with 02. (The only remaining code is 01 = user congestion).
  1266.  
  1267. 6.4. Data-phase TSDU
  1268.  
  1269. This is the core of the skinny stack. The lengths shown use a
  1270. particular set of choices for indefinite and definite lengths that
  1271. means that the application data length only affects one field. Making
  1272. the two earlier indefinite lengths definite would require more
  1273. calculation - adding 4 octets after the application data is assumed to
  1274. be quicker. This header is also designed to be 20 octets long, thus
  1275. maintaining 4-byte alignment between transport and application
  1276. buffers. Implementations are recommended to use this encoding. It is
  1277. possible to rapidly match incoming data against it - if there is no
  1278.  
  1279.  
  1280. Expires 17 April 1994                                         [Page 20]
  1281.  
  1282.  
  1283.  
  1284. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1285.  
  1286.  
  1287.  
  1288. mismatch until the length field, the location of the beginning of the
  1289. data can be determined without further analysis.
  1290.  
  1291.  
  1292.  
  1293.           SPDUs
  1294. 01  00  .      - S-GIVE-TOKEN - required by basic concatenation
  1295.                - but no parameters
  1296. 01  00  .      - S-DATA - no parameters - what follows is User
  1297.                - Information, not User Data, so is not included in the
  1298.                - SPDU length fields
  1299.   - P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
  1300. 61  80  {1     - User-data [APPLICATION 1]
  1301. 30  80  {2     - [SEQUENCE] PDV-list
  1302. 02  01  03     - [INTEGER] pcid for application data, P-CONNECT PPDU
  1303.                - remembered by both sides
  1304. 81  83yyyyyy   xxxxxx  --  [1] octet-aligned presentation data value(s)
  1305.               -- length of length (3 octets) then three octets yyyyyy
  1306.               -- for the length of the user data xxxxxx
  1307. 00  00  }2      - End-of-contents for end of PDV-list
  1308. 00  00  }1      - End-of-contents for end of Presentation User-data
  1309.  
  1310.  
  1311. If the application data is in ASN.1, and a single ASN.1 value is being
  1312. sent on the TSDU, the same header can be used except for the tag on
  1313. the presentation data values, which becomes A0 (= [0], constructed).
  1314.  
  1315. If there are multiple data values to be sent, this header can be
  1316. expanded in several ways:
  1317.  
  1318.       a) if there are several ASN.1 values from the same presentation
  1319.       context, they can be concatenated and treated as an octet-
  1320.       aligned value (using the header as shown above, with tag 81 (or
  1321.       A1 - I think its primitive) or  each ASN.1 value can be an item
  1322.       (tagged A0), one after the other
  1323.  
  1324.       b) if the data values are from different presentation contexts
  1325.       (group IV), each is in its own {2} group within the {1}.
  1326.  
  1327. On receipt, for the simple octet-aligned case, the data value may
  1328. itself have a constructed encoding - this will make the tag A1, and it
  1329. will contain elements each tagged 04 (OCTET STRING). According to
  1330. CULR-1, these elements are primitive (otherwise they would be 24 of
  1331. course).
  1332.  
  1333. 6.5. Closedown  - release request
  1334.  
  1335. When all is done, and you want to close down gracefully, send this on
  1336. T-DATA.
  1337.  
  1338.     - FINISH SPDU
  1339. 09  10  {1         - 9 identifies FINISH
  1340. *   Ls  ?          - No Transport Disconnect item
  1341.                    - default is release Transport-connection
  1342. C1  0E  {2         - User data (code 193)
  1343.  
  1344. Expires 17 April 1994                                         [Page 21]
  1345.  
  1346.  
  1347.  
  1348. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1349.  
  1350.  
  1351.  
  1352.     - P-RELEASE req/ind PPDU (has no name)
  1353. 61  80  {3         - [APPLICATION 1], user data, fully-encoded
  1354. 30  80  {4         - [SEQUENCE] PDV-list
  1355. 02  01  01         -- pcid for ACSE, remembered from setup
  1356. A0  80  {5         - [0] single asn.1-type
  1357.     - A-RELEASE request APDU - RLRQ
  1358. 62  80  {6         - [APPLICATION 2] identifies RLRQ
  1359. 80  01  00         - [0] reason, value 0 means normal
  1360. *   La  ?
  1361.          -- the user information field may or may not be required
  1362.          - ( not required for Group I)
  1363. ?BE 80  {7       - [30] IMPLICIT SEQUENCE
  1364. ?08 80  {8       - [EXTERNAL]
  1365.                  -- the transfer-syntax oid is not present this time
  1366. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1367. ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
  1368.                  -- (see note at end of 6.1)
  1369. ?00 00  }8       - end of EXTERNAL
  1370.          -- conceivably there may be several EXTERNALS, probably in
  1371.          -- different presentation contexts (different pcids)
  1372. ?00 00  }7       - end of user information field
  1373. 00  00  }6         - end of RLRQ
  1374. 00  00  }5         - end of single asn.1-type
  1375. 00  00  }4         - end of PDV-list
  1376. 00  00  }3         - end of Presentation User-data
  1377. .   .   }2         - end of session user data
  1378. .   .   }1         - end of FINISH SPDU
  1379.  
  1380.  
  1381.  
  1382. 6.6. Closedown - release response
  1383.  
  1384. On receiving a FINISH, you send this to tell the other end it is all
  1385. over
  1386.  
  1387.     - Session DISCONNECT SPDU
  1388. 0A  10  {1         - SI=10, DISCONNECT
  1389. C1  0E  {2         - User data (tag = C2 if length >512)
  1390.     - P-RELEASE rsp PPDU
  1391. 61  80  {3         - [APPLICATION 1], user data, fully-encoded
  1392. 30  80  {4         - [SEQUENCE] PDV-list
  1393. 02  01  01         -- [INTEGER] pcid for ACSE, remembered from setup
  1394. A0  80  {5         - [0] single asn.1-type
  1395.     - A-RELEASE response APDU - RLRE
  1396. 63  80  {6         - [APPLICATION 3] identifies RLRE
  1397. 80  01  00         - [0] reason, value 0 means normal
  1398. *   La  ?
  1399.          -- the user information field may or may not be required
  1400.          - (not required for Group I)
  1401. ?BE 80  {7       - [30] IMPLICIT SEQUENCE
  1402. ?08 80  {8       - [EXTERNAL]
  1403.                 -- the transfer-syntax oid is not present this time
  1404. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1405. ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
  1406.                  -- (see note at end of 6.1)
  1407.  
  1408. Expires 17 April 1994                                         [Page 22]
  1409.  
  1410.  
  1411.  
  1412. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1413.  
  1414.  
  1415.  
  1416. ?00 00  }8       - end of EXTERNAL
  1417.          -- conceivably there may be several EXTERNALS, probably in
  1418.          -- different presentation contexts (different pcids)
  1419. ?00 00  }7       - end of user information field
  1420. 00  00  }6         - end of RLRE
  1421. 00  00  }5         - end of single asn.1-type
  1422. 00  00  }4         - end of PDV-list
  1423. 00  00  }3         - end of Presentation userdata
  1424. .   .   }2         - end of session userdata
  1425. .   .   }1         - end of DISCONNECT SPDU
  1426.  
  1427. 6.7. Deliberate abort
  1428.  
  1429. It is not clear whether this is any use - just clearing the Transport
  1430. connection will be more effective. It goes on T-DATA, but asks for the
  1431. far-side to close the T-connection.
  1432.  
  1433.     - Session ABORT SPDU
  1434. 19  15  {1      - SI of 25 is ABORT
  1435. 11  01  03      - Transport Disconnect PV, code 17
  1436.                 --  value = '...00011'b means please
  1437.                 -- release T-conn, user abort
  1438. *   Ls  ?
  1439. C1  11  {2      - Session User Data
  1440.     - P-U-ABORT PPDU - ARU
  1441. A0  80  {3      - [0] implicit sequence for normal mode
  1442. A0  80  {4      - [0] presentation-context-identifier-list
  1443. 30  80  {5      - [SEQUENCE]
  1444. 02  01  01      - [INTEGER]pcid for ACSE
  1445. 06  02  5101    - [OID] for acse transfer syntax = BER
  1446. 00  00  }5
  1447.          -- there will be one {6} group for each application
  1448.          -- presentation context that is used in this message
  1449.          -- if there is no user data, the {6} group can be
  1450.          -- omitted
  1451. 30  80  {6
  1452. 02  01  03      - [INTEGER] pcid for application data
  1453. 06  La  xxxxxx  - [OID] transfer syntax for application data
  1454. 00  00  }6
  1455. 00  00  }4      - end of presentation-context-identifier-list
  1456. 61  80  {7      - [APPLICATION 1], user data, fully-encoded
  1457. 30  80  {8      - [SEQUENCE] PDV-list
  1458. 02  01  01      - [INTEGER] pcid for ACSE as on CP PPDU
  1459. A0  05  {9      - [0] single asn.1-type
  1460.     - A-ABORT APDU - ABRT
  1461. 64  80  {10     - [APPLICATION 4] identifies ABRT
  1462. 80  01  01      -  [0] value 1 is acse-service-provider
  1463.          -- the user information field may or may not be required
  1464. ?BE 80  {11      - [30] IMPLICIT SEQUENCE
  1465. ?08 80  {12      - [EXTERNAL]
  1466.                 -- the transfer-syntax oid is not present this time
  1467.                 -- (according to CULR-1)
  1468. ?02 01  03       - [INTEGER] this is the pcid for the application data
  1469. ?A0 La  xxxxx    -- [0] single-ASN.1-type application data
  1470.                  -- (see note at end of 6.1)
  1471.  
  1472. Expires 17 April 1994                                         [Page 23]
  1473.  
  1474.  
  1475.  
  1476. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1477.  
  1478.  
  1479.  
  1480. ?00 00  }12      - end of EXTERNAL
  1481.          -- conceivably there may be several EXTERNALS, probably in
  1482.          -- different presentation contexts (different pcids)
  1483. ?00 00  }11      - end of user information field
  1484. 00  00  }10     - end of ABRT
  1485. 00  00  }9      - end of single asn.1-type
  1486. 00  00  }8      - end of PDV-list
  1487. 00  00  }7      - end of Presentation user-data
  1488. 00  00  }3      - end of ARU-PPDU
  1489. .   .   }2      - end of session user-data
  1490. .   .   }1      - end of ABORT SPDU
  1491.  
  1492.  
  1493. 6.8. Provider abort
  1494.  
  1495. Generated when an internal error occurs (i.e. something has gone
  1496. mildly (?) wrong in the cookbook implementation). Rather than accuse
  1497. anyone of protocol errors, we just abort at session.
  1498.  
  1499.           ABORT SPDU
  1500. 19  03  {1         - SI=25 = ABORT SPDU
  1501. 11  01  09         - Transport Disconnect PV, code 17
  1502.                  -- value = '...01001'b  release T-conn
  1503.                  --  no reason
  1504. *   Ls  ?
  1505. .   .   }1
  1506.  
  1507. 6.9. Abort accept
  1508.  
  1509. If a Session abort (of any kind) is sent, it is possible that the far-
  1510. end will send back an abort accept. If this happens, disconnect the
  1511. transport. (The abort messages above do not propose that the transport
  1512. connection be reused, and in this case, an abort accept is just the
  1513. far-end passing the transport-disconnect initiative back.) This
  1514. session message need never be sent - just disconnect transport on
  1515. receiving an abort.
  1516.  
  1517.           ABORT ACCEPT SPDU
  1518. 1A  00  .         - SI=26 = ABORT ACCEPT SPDU, no parameters
  1519.  
  1520.  
  1521. 7. References
  1522.  
  1523. [CULR-1] Working draft 13 of Common upper layer requirements - Part 1
  1524. : basic connection-oriented requirements; EWOS. (A later draft will be
  1525. proposed as ISP 11188/1)
  1526.  
  1527. [CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal
  1528. OSI upper layers facilities (A later draft will be proposed as ISP
  1529. 11188/3)
  1530.  
  1531. [ISO8072] Information processing systems - Open Systems
  1532. Interconnection - Transport service definition; ISO, 1986.
  1533.  
  1534.  
  1535.  
  1536. Expires 17 April 1994                                         [Page 24]
  1537.  
  1538.  
  1539.  
  1540. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1541.  
  1542.  
  1543.  
  1544. [ISO8073] Information processing systems - Open Systems
  1545. Interconnection - Transport protocol specification; ISO, 1986.
  1546.  
  1547. [ISO8326] Information processing systems - Open Systems
  1548. Interconnection - Basic connection oriented session service
  1549. definition; ISO, 1987. (or review copy of revised text = ISO/IEC
  1550. JTC1/SC21 N4657, April 1990)
  1551.  
  1552. [ISO8327] Information processing systems - Open Systems
  1553. Interconnection - Basic connection oriented session protocol
  1554. specification; ISO, 1987. (or review copy of revised text = ISO/IEC
  1555. JTC1/SC21 N4656, April 1990)
  1556.  
  1557. [ISO8649] Information processing systems - Open Systems
  1558. Interconnection - Service definition for the Association Control
  1559. Service Element; ISO, 1989
  1560.  
  1561. [ISO8650] Information processing systems - Open Systems
  1562. Interconnection - Protocol specification for the Association Control
  1563. Service Element; ISO, 1989
  1564.  
  1565. [ISO8822] Information processing systems - Open Systems
  1566. Interconnection - Connection-oriented presentation service definition;
  1567. ISO, 1989
  1568.  
  1569. [ISO8823] Information processing systems - Open Systems
  1570. Interconnection - Connection-oriented presentation protocol
  1571. specification; ISO, 1989
  1572.  
  1573. [ISO8824] Information technology - Open Systems Interconnection -
  1574. Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990
  1575.  
  1576. [ISO8825] Information technology - Open Systems Interconnection -
  1577. Specification of Basic Encoding Rules for Abstract Syntax Notation
  1578. One, ISO/IEC 1990
  1579.  
  1580. [RFC1006] ISO transport services on top of the TCP; Rose M.T, Cass
  1581. D.E, 1987
  1582.  
  1583. [ISO9594] Information technology - Open Systems Interconnection - The
  1584. Directory; ISO/IEC, 1990
  1585.  
  1586. [RFC 1274] The Internet and Cosine Schema; Kille, S.H., 1992
  1587.  
  1588.  
  1589.  
  1590.  
  1591. 8. Other notes
  1592.  
  1593. The Session, Presentation and ACSE standards have been the subject of
  1594. considerable amendment since their first publication. The only one
  1595. that is significant to this cookbook is Session addendum 2, which
  1596. specifies session version 2 and unlimited user data. There are plans
  1597. to produce new editions of these standards, incorporating all the
  1598. amendments, published in early 1994.
  1599.  
  1600. Expires 17 April 1994                                         [Page 25]
  1601.  
  1602.  
  1603.  
  1604. INTERNET DRAFT       ThinOSI upper-layers cookbook         October 1993
  1605.  
  1606.  
  1607.  
  1608. The coding choices made in the cookbook are (nearly) those made by the
  1609. "Canonical Encoding Rules", which are a form of Basic Encoding Rules
  1610. with no optionality, specified in an amendment to ISO/IEC 8825
  1611. (currently a new part of 8825 at Draft International Standard status,
  1612. but likely to be folded into a new edition of 8825). A defect report
  1613. has been proposed against Presentation and ACSE, suggesting that a
  1614. note to the protocol specifications recommend use of the canonical
  1615. encoding options when sending, and then optimising for this on
  1616. receipt.
  1617.  
  1618.  
  1619. 9. Author's Address
  1620.  
  1621. Peter Furniss
  1622. Peter Furniss Consultants
  1623. 58 Alexandra Crescent
  1624. Bromley, Kent BR1 4EX
  1625. UK
  1626.  
  1627. Phone & fax +44 81 313 1833
  1628.  
  1629. Email: P.Furniss@ulcc.ac.uk
  1630.  
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657.  
  1658.  
  1659.  
  1660.  
  1661.  
  1662.  
  1663.  
  1664. Expires 17 April 1994                                         [Page 26]
  1665.  
  1666.